2 test cases from this PR are a ? to me:

• tests/asyncapi-2.0/Message Trait Object/invalid-missing-content-type.yaml
• tests/asyncapi-2.0/Message Object/invalid-missing-contentType.yaml

contentType and defaultContentType fields are not required by the spec, so in my opinion these test cases should be removed, probably in another PR for clarity? as I think it would mean we also remove tests/asyncapi-2.0/Message Object/valid-using-defaultContentType.yaml and tests/asyncapi-2.0/Message Trait Object/valid-using-defaultContentType.yaml

2 test cases from this PR are a ? to me:

* `tests/asyncapi-2.0/Message Trait Object/invalid-missing-content-type.yaml`

* `tests/asyncapi-2.0/Message Object/invalid-missing-contentType.yaml`

contentType and defaultContentType fields are not required by the spec, so in my opinion these test cases should be removed, probably in another PR for clarity? as I think it would mean we also remove tests/asyncapi-2.0/Message Object/valid-using-defaultContentType.yaml and tests/asyncapi-2.0/Message Trait Object/valid-using-defaultContentType.yaml

I've added these tests because, for example, this section says:

The content type to use when encoding/decoding a message's payload. The value MUST be a specific media type (e.g. application/json). When omitted, the value MUST be the one specified on the defaultContentType field.

Thus I assumed that either contentType or defaultContentType must be specified.

Feel free to open an issue so we can discuss this further.

I think you found a gap in the spec, @postatum. There should be a default value for defaultContentType or otherwise make it required (which I don't like). Can you create an issue on asyncapi/asyncapi repo?

I think you found a gap in the spec, @postatum. There should be a default value for defaultContentType or otherwise make it required (which I don't like). Can you create an issue on asyncapi/asyncapi repo?

Done asyncapi/spec#421

Thanks, mate!

created this issue to followup on the discussion #27